Una aplicación móvil para consultar artículos en Wikipedia
1. Definir los requisitos de negocio (3 puntos, 1 punto cada apartado)
1.1 Enunciar la visión del producto
Para todos las personas que utilizan Wikipedia, WikiPhone es la mejor experiencia Wikipedia en tu dispositivo móvil. A diferencia de otras aplicación similares, WikiPhone permitirá a sus usuarios poder consultar artículos de Wikipedia, guardarlos para leerlos más tarde, descargarlos e incluso tomar notas sobre los artículos descargados.
1.2 Enunciar dos objetivos de negocio, con sus correspondientes métricas de éxito
Objetivos de negocio
O1. Alcanzar una base de 10000 usuarios activos en el primer semestre desde el lanzamiento.
O2. Obtener un NPS (Net Promoter Score) de al menos el 30% por nuestra base de usuarios en el primer semestre desde el lanzamiento.
Métricas de éxito
O1. Alcanzar una base de 10000 usuarios activos en el primer semestre desde el lanzamiento.
Se contabiliza como usuario activo toda cuenta que haya realizado un login, al menos, una vez durante la semana en la que se realiza la medición.
O2. Obtener un NPS (Net Promoter Score) de al menos el 30% por nuestra base de usuarios en el primer semestre desde el lanzamiento.
NPS (Net Promoter Score): con ella obtendremos métricas para medir la fidelización y satisfacción del usuario. Esta métrica se obtendrá a partir de una pequeña encuesta de una pregunta: “¿Qué probabilidades hay de que recomiendes WikiPhone a otros usuarios?”
El NPS se calculará restando el porcentaje de personas encuestadas que votaron entre 0 y 6 (Detractores) del porcentaje de personas que votaron entre 9 y 10 (Promotores) .
NPS = Promotores (%) - Detractores (%)
1.3 Identificar 4 tipos de stakeholders. Clasificarlos de algún modo: usuarios; clientes: dentro o fuera de la organización desarrolladora; usuarios directos o indirectos; usuarios favorecidos, desfavorecidos o ignorados…
Lista de stakeholders
S1. Usuarios básicos: Población general que hacen uso de la Wikipedia. Utilizan la aplicación de manera gratuita.
S2. Inversores: Personas no pertenecientes a la organización que buscan obtener una rentabilidad con sus inversiones.
S3. Desarrollador: Son los programadores, analistas o cualquier miembro del equipo técnico que participa en el desarrollo de la aplicación.
S4. Hackers: Usuarios malintencionados, que intentan acceder a la plataforma para ejercer un uso fraudulento, como robar datos de usuarios.
Clasificación
Interno o externo: Si están dentro o no de la organización o forman parte del equipo de desarrollo.
Directo o indirecto: Si es usuario o no, en caso de ser usuario, será directo si se beneficia directamente de la aplicación o indirecto si se beneficia de sus resultados.
Favorecido, desfavorecido, ignorado u otros:
Favorecidos, son a los que les ofrecemos funcionalidades que les aportan valor.
Desfavorecidos, son los usuarios a los que quiero impedir el uso de la aplicación.
Ignorados, usuarios irrelevantes.
Otros, los que no podemos clasificar en ninguna de las clases anteriores.
| ID | Stakeholders | Interno o externo | Directo o indirecto | Favorecido, desfavorecido, ignorado u otros |
|---|---|---|---|---|
| S1 | Usuario básico | Externo | Directo | Favorecido |
| S2 | Inversor | Externo | Indirecto | Favorecido |
| S3 | Desarrollador | Interno | --- | Otros |
| S4 | Hackers | Externo | Indirecto | Desfavorecido |
2. Definir requisitos de los usuarios (3 puntos, 1 punto cada apartado)
2.1 Seleccionar una clase de usuario e identificar para ella 4 casos de uso. Documentar cada uno de los casos de uso según la plantilla que se indica al final del enunciado. Representar además los casos de uso en un diagrama de casos de uso.
Casos de uso
| ID | UC01 |
|---|---|
| Nombre del caso de uso | Consultar artículo |
| Descripción | Como usuario básico, necesito poder consultar articulos para poder informarme de lo que necesite en cada momento. |
| Actores | Usuario básico |
| ID | UC02 |
|---|---|
| Nombre del caso de uso | Descargar artículo |
| Descripción | Como usuario básico, necesito poder descargar artículos para poder consultarlos y editarlos sin necesidad de permanecer en conectado a internet. |
| Actores | Usuario básico |
| ID | UC03 |
|---|---|
| Nombre del caso de uso | Guardar artículo |
| Descripción | Como usuario básico, necesito poder guardar mis artículos favoritos para poder consultarlos en otro momento. |
| Actores | Usuario básico |
| ID | UC04 |
|---|---|
| Nombre del caso de uso | Editar articulo descargado |
| Descripción | Como usuario básico, necesito poder editar los articulos descargados para hacer mis anotaciones personales sobre dicho artículo. |
| Actores | Usuario básico |
Diagrama de casos de uso
2.2 Seleccionar un caso de uso de los elaborados en la sección anterior, y documentar sus escenarios empleando una secuencia de pasos numerada, o un diagrama de flujo (solo una de las dos opciones). No escojas un caso de uso trivial. que podria ser común a muchas aplicaciones, como el registro o el login. Que sea un caso de uso específico del dominio de aplicación considerado.
Caso de uso: UC04 Editar artículo descargado
PRE04.1 El usuario ha iniciado sesión.
PRE04.2 El usuario ha descargado un artículo.
PRE04.3 El usuario ha accedido a la sección de artículos descargados.
UC04.1 El usuario selecciona el artículo que desea editar.
UC04.2 El sistema muestra la página de edición de artículo.
UC04.3 El usuario realiza la edición sobre el artículo.
UC04.4 El usuario indica que a finalizado la edición.
UC04.5 El sistema agrega las modificaciones al artículo descargado.
UC04.6 El sistema mostrará un mensaje de confirmación de finalización.
2.3 Priorizar los 4 requisitos de usuario elaborados empleando la técnica de valor (ponderación del 0,5), coste (ponderación del 0,5) y riesgo (ponderación del 0,5).
| Ponderaciones | |||||||
| US01 Consultar artículo | |||||||
| US02 Descargar artículo | |||||||
| US03 Guardar artículo | |||||||
| US04 Editar artículo descargado | |||||||
| Sumas | |||||||
3. Definir la especificación detallada del sistema (2 puntos, 1 punto cada apartado)
3.1 Para 2 casos de uso identificados, elaborar una especificación funcional detallada del sistema empleando la plantilla EARS.
Caso de uso: UC03 Guardar artículo
RF01: CUANDO el usuario seleccione "guardar artículo", el sistema DEBERÁ mostrar las siguientes opciones de guardado:
Crear categoría
Guardar en categoría existente
RF02: CUANDO el usuario confirme el guardado del artículo, el sistema DEBERÁ guardar el enlace del artículo en la categoría seleccionada por el usuario.
RF03: CUANDO el sistema guarde el artículo, el sistema DEBERÁ mostrar un mensaje de confirmación de finalización.
RF04: SI el sitema detecta que el artículo ya ha sido guardado con anterioridad, CUANDO el usuario confirme el guardado del artículo, el sistema DEBERÁ mostrar un mensaje indicando al usuario que "el artículo ya ha sido guardado con anterioridad".
Caso de uso: UC04 Editar artículo descargado
RF05: CUANDO el usuario seleccione la opción de editar artículo, el sistema DEBERÁ dirigirle a la sección de edición de artículos donde podra:
Subrayar
Marcar
Insertar texto
RF06: CUANDO el usuario finalice la edición del artículo, el sistema DEBERÁ mostrar un aviso solicitando si se desea sobreescribir el artículo o guardar como nuevo artículo.
RF07: CUANDO el artículo editado es guardado en el sistema, el sistema DEBERÁ mostrar un mensaje de confirmación de finalización.
3.2 Elaborar una matriz de trazabilidad entre casos de uso y los requisitos funcionales que has generado en el paso anterior.
| UC01 | UC02 | UC03 | UC04 | |
|---|---|---|---|---|
| RF01 | X | |||
| RF02 | X | |||
| RF03 | X | |||
| RF04 | X | |||
| RF05 | X | |||
| RF06 | X | |||
| RF07 | X |